1. Field of the Invention
The present invention relates to networking and, more particularly, to a method and apparatus for supporting location registration and mobility for each service flow in relation to a Mobile Node (MN) having a plurality of wired/wireless network interfaces in a wired/wireless integrated network environment.
2. Discussion of the Related Art
At the present time, not only wired communication techniques, such as Ethernet and Fiber-To-The-Home (FTTH), but also a variety of radio access techniques, such as a Wireless Local Area Network (WLAN), Wibro, 3G (e.g., CDMA), and 3.5G (e.g., HSPA), appear, and they are being provided to users. In line with a change in this communication environment, active researches are being carried out on uniquitous mobile networking service in order to provide users with various convergence multimedia services having optimum quality anytime and anywhere by combining a variety of wired/wireless techniques for the interworking of heterogeneous networks.
For multimedia service through a plurality of communication networks, communication technology that is focused on a multi-mode MN on which a plurality of wired/wireless interfaces is mounted becomes influential. Accordingly, it is necessary to supplement and modify networking techniques that are taken into account in a single-mode MN on which the existing node interface is mounted. In the existing MN mobility technique, how each service flow will be managed has not been taken into account in a situation in which a number of communication connections are maintained because the existing MN mobility technique has been chiefly developed based on a handover control function for switch between network interfaces and processing a change of a network access path. In particular, the choice of an interface based on a service data character is important because Quality of Service (QoS) characteristics provided by networks are different from one another. Furthermore, if a specific interface is not capable of communication due to reasons, such as a movement of an MN or the quality of a network, data flows that use the specific interface have to be redistributed over other interfaces. Accordingly, mobility support method for each service, that is, flow-based mobility support technology, must be taken into consideration in order to provide service to each flow in an optimum network environment by incorporating the characteristics of specific service (or flow) and subscriber preference into the mobility support method.
At the present time, regarding the flow-based mobility support technology, researches are focused on network-based IP mobility support technology (e.g., IETF Proxy MIPv6 (PMIPv6)) rather than on node-based Internet Protocol (IP) mobility support technology (e.g., IETE Mobile IPv6). In PMIPv6, a Mobile Access Gateway (MAG) function is embodied in the access router of an MN, and a core network has a Local Mobility Anchor (LMA) function. PIMPv6 describes a procedure in which if an MN moves to an area managed by an MAG, the MAG registers mobility binding information on the MN with an LMA. That is, in accordance with PMIPv6, an MN in which a function for IP mobility management (e.g., Mobile IPv6) has not been embodied can manage IP mobility through signaling between an MAG and an LMA within a network. Here, an LMA operates a kind of Home Agent (HA) for an MN within an access network, and an MAG supports the mobility of an MN instead of the MN.
Furthermore, researches are carried out on the support of flow-based mobility by extending and improving PMIPv6 on the basis of ‘Internet Engineering Task Force Net work-based Mobility Extension Working Group (IETF NETEXT WG)’. More particularly, the following schemes are being discussed.
(1) An article “Service Flow Identifier in Proxy Mobile IPv6 (draft-hui-netext-service-flow-identifier-00)” defines the format of a service flow identifier option for informing an LMA of specific service flow information in PMIPv6 and proposes a method of including the format in control messages that are exchanged by an MN in handover processing. In the method proposed by the article, a point of time at which an MN uploads this service flow identifier option onto an LMA is determined as the time when an MAG receives packets, belonging to a new service flow, from a specific interface of the MN. This method, however, is problematic in that necessary service flow binding is requested only when data traffic of a new service flow, that is, uplink packets, is transmitted from an MN to an MAG and this service flow binding cannot be requested when the traffic is transmitted from a Corresponding Node (CN) to a corresponding MN. Accordingly, if downlink traffic arrives at an LMA while uplink traffic is temporarily absent after handover, the downlink traffic arrives at an interface that is now unwanted by the MN.
(2) An article “Flow Binding in Proxy Mobile IPv6 (draft-xia-netext-flow-binding-00)” proposes a method of reusing a flow label that is used to manage flows in Mobile IPv6 without newly defining the format of a service flow identifier option. However, a binding policy for each service for inducing service flow handover depends on the profile of an MN or a service provider policy. That is, a binding method regarding a specific flow is stored in a database for managing several pieces of information on an MN, and service flow binding is started based on the stored information. The method proposed by this article is problematic in that a user who uses an MN actually lets management for each flow to be performed on the basis of only static and previously stored information irrespective of desired preference. For example, if there is statement that VoIP service traffic must be exchanged through a WLAN interface in a previously stored profile, a user may want to use VoIP service using a 3GPP interface according to circumstances. In this case, the VoIP service is not supported in the method proposed by this article.
(3) An article “Flow Handover for Proxy Mobile IPv6 (draft-koodli-netext-flow-handover-00)” defines additional signaling messages for flow handover and proposes a method of putting an IP address and a port number into each flow label. Like the method (2), this method is problematic in that dynamic user preference cannot be incorporated because this method depends on the static profile of an MN or the policy of a service provider and thus generates the handover of a service flow.